Graphical user interfaces (GUIs) have developed to become essential interfaces for many computer applications. For example, electronic design automation (EDA) is one application, including such uses as schematic design and layout design in which the designs for components and spatial layout of electronic components such as integrated circuits, circuit boards and other components are viewed, created and edited using displayed images and graphical controls. Designers use graphical display software tools to display, navigate, create and edit circuit schematics and layout designs as well as other types of designs.
User interfaces of modern EDA tools are now extremely complex, which is a reflection of the complexity of the modern integrated circuit (IC) design process itself. As the capability and complexities of IC manufacturing processes has increased over time, and the capability and complexity of the circuit design process and its tools has grown in a corresponding manner, the relative ease-of-use of many such tools has degraded significantly when they are compared with their earlier and simpler versions. By this it is meant that in today's EDA GUIs, access to important functionality and options is often hidden in deeply nested submenus and sub-dialogs, making them difficult for a user to find and interact with. This problem is not limited to the IC design area and EDA tool space, and the issues of managing user interface complexity have also arisen for other applications such as word processing, presentations, and spreadsheets have evolved substantially over many years into more capable and more complex tools, necessitating the authors of such tools to find techniques to simplify their otherwise overly complex interfaces.
One simplification solution of recent times has been to place more and more functionality (previously accessible only through sub-dialogs) into “state-bearing” graphical controls such as menu and toolbar elements, which are more easily accessed by a user. A state-bearing control can visually bear state from a set of mutually exclusive offered options, and is not just limited to a direct action as has traditionally been the case with menu and toolbar callbacks. One non-EDA example of a state bearing toolbar item is a text justification option in some applications such as word processors or presentation software. The user can choose one of offered options for a piece of selected text, and the state of that choice is then updated and visually presented in both that same submenu and in other areas of the GUI, such as in another menu or toolbar. The displayed state is updated to the current state of any selected text, e.g., whenever that piece of text is again selected, the associated state is displayed in those controls. The state is visually and clearly indicated by the GUI element in both the menu and the toolbar, e.g. via checkboxes, borders, or other indication. Another such example is a toolbar item providing a dropdown menu that allows the user to change a text highlight color for a piece of selected text. The toolbar item visually changes its state to illustrate the corresponding text attribute of any currently highlighted piece of text. Yet another example is a toolbar menu box for indicating font and/or font size for selected text, and allowing the user to view and/or select a font and font size. Such commonly used controls are readily accessible and visible, and do not consume a significant amount of screen real-estate, since they use a small icon to indicate the state, and only transiently use a larger screen area when the user interacts with them to change their state.
In contrast, current EDA software does not employ these features. For example, to change the default font height for Pin Labels, a user may have to first navigate to the correct options dialog (of which there may be several), and then find/choose the correct Tab within that dialog, in order to gain access to the corresponding control. It would be far easier on the EDA tool user to have a box in a toolbar and/or an analogous sub-menu which presented the most commonly used pin label font sizes to choose from. The visual simplicity and real estate economy of these approaches is clear and valuable. Such benefits would also be extremely valuable to users of even more complex applications, such as EDA applications.
EDA applications are extremely extensible and programmable by end users, CAD groups, and/or other users. This is because the IC design complexity is sufficiently high that no single EDA program can perform all desired functions, and so users often implement their own specific design needs in applications by extending the functionality of a vendor-supplied EDA application in an “aftermarket” fashion. It would therefore be desirable for users doing such application extensions to be able to provide GUI controls for their extended/customized functionality using simple space-efficient, state-bearing GUI controls in multiple places of a GUI, such as across multiple menus and/or toolbars.
However, there are issues related to the synchronization of states of such controls when used in multiple places of a GUI, and the efficient re-use of such controls across multiple design windows or “tabs” in a tabbed document interface. For example, some EDA GUIs in general allow for multiple windows to be opened simultaneously, and further, a tabbed interface in some EDA applications allows for any given such window to contain multiple tabs, where each such tab selects a different cell (or other view or displayed portion) in a hierarchical design, such as a layout design, schematic design, etc. There can therefore be quite a number of design cells or other design views opened at the same time. A list of menus and toolbars can be displayed above the active tab by the software for operating on the cell, or the data within the cell, among other functions. It is the EDA-specific toolbars and menus (at a minimum) that a user would wish to further customize, by creating additional or replacement state-bearing GUI controls including user-specific extended or additional functionality, such as checkbox items, radio buttons or other radio items, menu items, list boxes (or “comboboxes”), spinboxes, etc.
In typical applications, to allow self-synchronization of such multiple controls in different menus, toolbars, tabs, and applications, programmers must write complicated callback code that queries the system to determine the lists of all the open or active windows, tabs, applications, etc., and search these lists to find the same controls open in other places. Besides being a complex programming task, another problem with this approach is that the callback code becomes stale over time as additional controls are added to the applications.
In the case where the same general state-bearing control is made available in such a multiplicity of GUI locations, it is essential that these controls be maintained in a synchronized manner. For example, if a user should use a control in a Formatting toolbar to set the text foreground color to green, the same control in a Draw toolbar or other menu should also automatically have its state set to green. If an EDA tool user were to enable the grid using a grid on/off menu toggle, then a drafting toolbar or canvas-specific context menu which also contains a show/hide grid toggle button, should be also maintained in a synchronized state. Further complicating the situation is the need to be able to share resources differently on a plurality of levels, such as Globally, Per window, Per application, or Per tab of an application.
Thus there are a potentially large number of EDA GUI functionalities that would be better represented by state-bearing controls in today's complex EDA software. When this number of basic functionalities is multiplied by multiple design cells simultaneously open, multiple application windows open, multiple tabs open per application window, and multiple different locations (multiple toolbars, multiple menus) which can contain such controls, etc., the result is that there would be a very large number of such state-bearing (and resource consuming) controls created by the EDA framework. However, since the majority of these controls are not always visible by the user, it is further desirable to save memory and limit the number of controls created overall by sharing the resources for these controls as much as possible, and to synchronize the states of such controls. For a user, writing such highly optimized resource sharing and self-synchronizing code is extremely non-trivial, and very dependent on the architecture chosen by the original EDA software vendor. Hence any such written code is likely to be initially quite buggy, rapidly becoming stale/obsolete as the vendor tweaks the architecture (requiring rewrites), all of which ultimately leads to a situation whereby such controls will not be written or adopted en masse, thus defeating the purpose.
Accordingly, there is a need for a very flexible yet highly configurable software system which efficiently stores and automatically tracks and maintains multiple graphical controls for a GUI. There is also a need for a system which allows a user to easily define, manipulate and customize collections of such automatically-maintained GUI controls. The present inventions address such needs.